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SYSTEM AND METHOD FOR OUT-SOURCING THE 
FUNCTIONALITY OF SESSION INITIATION PROTOCOL (SIP) 
USER AGENTS TO PROXIES 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This application is related to commonly owned U.S. Patent application Serial 

No. (Attorney Docket APP 1357) filed concurrently herewith and 

entitled "System and Method For using Session Initiation Protocol (SIP) to Communicate 
with Networked Appliances." 

BACKGROUND OF THE INVENTION 

This invention relates to the communication of control signals and status 
signals over a network to effect operation of networked devices and, more particularly, to the 
use of Session Initiation Protocol to improved communications with a plurality of networked 
units. 

The Internet Engineering Task Force ("IETF') has developed a 
communications protocol called Session Initiation Protocol ("SIP") which can accommodate 
a number of different modes of communication. SIP, according to proposed standard RFC 
2543, is an application-layer control and signaling protocol for creating, modifying and 
terminating interactive communications sessions between one or more participants. It is a 
text-based protocol similar to HTTP and SMTP. These sessions may include voice, video, 
chat, interactive games and virtual reality, e.g., Internet multimedia conferences, Internet 
telephone calls and multimedia distribution. Members in a session can communicate via 
multicast or via a mesh of unicast relations, or a combination of these. 

SIP invitations (i.e., the SIP method INVITE) are used to create sessions. 
These invitations can carry session descriptions which allow participants to agree on a set of 
compatible media types. SIP supports user mobility by proxying and redirecting requests to 




the user's current location, which the user can register. SIP is not tied to any particular 
conference control protocol, but instead it is designed to be independent of the lower-layer 
transport protocol. 

The SIP architecture includes user agents, where a user agent is a device 
5 running an application program that can act as both a user agent client ("UAC") and a user 
agent server ("UAS"). A client is an application program that sends SIP requests. A client 
may or may not interact directly with a human user. 

A server is an application program that accepts requests from a client in order 
to service those requests and sends back responses to those requests. Thus, a UAS is a server 
io'q application that contacts the user when a SEP request is received and that returns a response 

^ J on behalf of the user. The response accepts, rejects or redirects the request. 

J 

^5 In addition there are servers which are not User Agents. These can be Proxy, 

'l| Redirect or Registrar servers. A Proxy server is an intermediary program that acts as both a 

server and a client for the purpose of making requests on behalf of other clients. Requests are 
15;^; serviced internally by the Proxy server or are passed by it to other servers, possibly after 
l-i- translation. A Proxy server interprets, and, if necessary, rewrites a request message before 
l^r forwarding it. In an Internet context, the Proxy server receives requests from a UAC, even 

when directed to a host with a different URL. After processing, it sends these on to the 

destination URL. 

2 0 A Redirect server is a server that accepts a SIP request, maps the address into 

zero or more new addresses and returns these addresses to the client. Unlike a UAC, it does 
not initiate its own SIP request. Unlike a UAC, it does not accept calls. 

A Registrar server is a server that accepts REGISTER requests. It keeps a list 
of the registered addresses it receives for the UAS devices in its area and is typically 

2 5 co-located with a Proxy or Redirect server so it can share its information with them. 
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In a SIP configuration the UAC sends a request to a UAS via one or more 
Proxy servers. Typically one UAC may address or be capable of addressing multiple UASs. 
Further, in a standard SIP architecture, endpoints, i.e., UASs, are always able to communicate 
directly with each other. Applying this structure to a typical multimedia conference, the 
control application would act as a UAC to initiate calls or to invite others to conferences and 
it would act as a UAS to accept invitations. The role of UAC and UAS as well as Proxy and 
Redirect servers are defined on a request-by-request basis. For example, the user agent 
initiating a call acts as a UAC when sending the initial INVITE request and as a UAS when 
receiving a BYE request from the device called. Similarly, the same software can act as a 
Proxy server for one request and as a Redirect server for the next request. The SIP UAS will 
typically be embedded in SIP phones, PCs and PDAs. These UAS devices are responsible 
for authenticating the originator of the message and then determining if that entity is 
authorized to perform the requested operation (typically by consulting an access control list). 

The remote control of appliances networked together is a new and growing 
area of interest. In a typical embodiment, a home can have all or many of its appliances 
connected to a network. With such a system, the homeowner can access the network and turn 
on the lights in the driveway, start the coffee maker, and raise or lower the temperature in the 
home, even before leaving the office. Also, the refrigerator can keep an inventory of your 
groceries and re-order when necessary. A clock can co-ordinate the user's agenda or perhaps 
turn on an appliance. To achieve this functionality, it is clear that these appliances need to 
communicate with each other so that, for example, the alarm clock can turn on the bedroom 
lamp. 

Networked Appliances (NAs) are dedicated consumer devices containing at 
least one networked processor. As an alternative, conventional appliances can be connected 
to an appliance controller which accepts remote messages and controls the appliance in the 
desired way. As a result, a substantial amount of computing power is need in each controller. 
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In Networked Appliance systems there can be the following considerations 
that need to be accommodated when considering communication outside of the home, 
notably: 

■ Security - In-home communication exploits a level of physical security that is lost 
5 when arbitrary access from outside of it is permitted. 

■ Authentication - The entity trying to enter into the home needs to be 
unambiguously identified prior to permitting access. 

■ Reliability - Because of the wide-area nature of extra-home access, there are more 
points of failure. The home should continue to operate independently of external 

lojo systems when communication with them is lost. 

^ J ■ Scaling - there are very many homes. 

7£J ■ Protocol Independence - Although within a single home it is acceptable that many 

different protocols are used for inter-device communication, a much more 
:„ protocol-independent approach is required for the wide area, since the exact details 

isj"^ of the devices comprising the in-home network may not be known from the 

H outside world. 

Mf ■ Naming and Location - Devices within the home need to be unambiguously 

named and their location identified from outside of it. 
Techniques are being developed to begin to allow control of devices in the home from the 
2 0 outside world, most notably by the Open Services Gateway Initiative (OSGi). See OSGi, 

www.osgi.org. However, this prior system still does not address the general problem of wide 
area access and security, as well as the other concerns expressed above. These systems do 
not provide a uniform protocol for communication over the Internet. In addition, these 
systems require a great deal of functionality at each controllable appliance or a separate 
25 appliance controller connected to the Networked Appliance, 



-4- 



• # 

APP 1300 

There are certain features of the SIP architecture that suggest that it might be 
useful for communications with Networked Apphances, but with more general applicability 
to any networked device in which the location phase and communication (or action) phases 
are merged into a single activity. In particular, SIP allows mobility, i.e., a recipient device 
can be moved so long as it is registered again at its new location. 

SIP is a transactional service, consisting of sequences of request-response 
transactions within a common context (identified by the Call-BD). This would also apply to a 
Networked Appliance connection where a conversation (session) is initiated by a first 
message and the responses and other messages are to be grouped together. Further, SEP uses 
MIME for transport of content. Thus, the meaning and purpose of the content depend on the 
request method and on the content type, SIP uses numerous header fields for identification 
of the users involved in the communication. This function would be useful in Networked 
Appliance connections. Further, SIP has authentication tools and security mechanisms that 
are necessary for Networked Appliance systems that allow remote access. 

Importantly, in a Networked Appliance system with access from outside the 
home, a requesting agent must send an instruction to perform an action on a named object in 
a message. The message would contains the name of the object upon which the action should 
be performed as its address, and the action itself as the payload. This message would be 
routed from agent to agent, resolving the name as it goes along. For example, the command 
"Switch on the lamp in the master bedroom in Dave's house" would first be routed to the 
server that knows the location of Dave's house. Then the message would be routed on to the 
firewall device at Dave's house, where access control and authorization is performed. If this 
is successful, the message payload is then delivered to the device to perform whatever action 
has been requested. 

In SIP this routing by name function is achieved in the INVITE process. In 
particular, an INVITE is sent first to an agent, or proxy, for the name. The Proxy can rewrite 
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the name and relay the INVITE, getting closer to the eventual destination for the message and 
delivering the payload (which is conventionally in a Session Description Protocol (SDP)) 
once it arrives. The processes for locating the intended recipient of the message and the 
action requested are intertwined in the same procedure. In addition, the SIP security 
5 architecture enables verification based on these high level names. 

However, there are two essential differences between the capabilities of SEP 
and the identified requirements for a communication with Networked Appliances. First, SIP 
location information is in the form of a URL, which is an Internet Domain Name Server 
(DNS) address. However, not all networked appliances have an IP address (e.g., an X.IO 
lo:^ device behind an appliance controller). Second, the only action that the SIP INVITE message 
Jl can perform is to set up a session with associated bearers, using SDP (or some other MIME 
^tt TYPE, e.g., ISUP/QSIG). Thus, it can set up a video conference, but INVITE is not designed 

to transmit messages that control a device. 
JL, Also, prior Networked Appliance systems have not provided security for 

1^ access from outside the home, events and media streaming, thus, it would be advantageous if 
M; SIP or some other system could be adapted to transmit messages that control a device. 
i-4 In co-pending conrunonly assigned patent application Serial No. 

(Attorney Docket APP 1357) filed concurrently herewith, a method of 

modifying SIP to overcome these problems is disclosed. In particular, a new method called 
2 0 DO, i.e., a new MIME type and addressing scheme was created and applied to SIP in order to 
allow command and query communications with Networked Appliances using the SIP 
format. Further, methods called SUBSCRIBE and NOTIFY, which were created by others 
for Instant Messaging as extension to SIP, are used in the other application in order to send 
control messages to Networked Appliances and to receive status information from them. 
2 5 This other application is incorporated herein in its entirety. 



-6- 




APP 1300 

SUMMARY OF THE INVENTION 

The present invention is directed to improvements in Session Initiation 
Protocol in general and to the remote control of Networked Appliances using a modified SIP 
network in particular. 

5 In a preferred embodiment of the present invention certain functions are 

moved from SIP User Agents to SIP Proxy servers (either network-based or gateway-based). 
These functions include address mapping, authentication, authorization and translation. As a 
result, the processing and memory storage requirements at the agent servers is reduced, 
creating an overall savings in computing requirements for remote devices. This requires that 

1 o;^ the access control information for each UAS be provided in the SIP Proxy server. If the SIP 

.^1 messages are end-to-end encrypted from the UAC to the UAS, then either: (1) the messages 
''^ must be encrypted with the Proxy's encryption key and the UAS must provide the Proxy with 
^ij its encryption key or (2) the UAS must decrypt the message and send it back to the Proxy for 
JL^ authentication and authorization. The transntiission of the Proxy's encryption key can be 
15;=^; accomplished with a SIP REGISTER message. After the Proxy server performs the 
M/ authentication and authorization it will only forward the message to the UAS if the 
H authorization succeeds. 

In addition to moving the authentication and authorization functions to the 
Proxy, when using the invention for Networked Appliances, the address mapping function is 

2 0 also moved to the Proxy server when SIP is used for the control of Networked Appliances. 

As a result, the UAS only needs to recognize its address and does not need to map the address 
further. If the message is not meant for it, it will not receive it and the Proxy server will send 
it to the correct destination. Further, the protocol translation function is also moved from the 
UASs to the Proxy servers in a similar manner. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other features of the present invention will be more readily 
apparent from the following detailed description and drawings of an illustrative embodiment 
of the invention in which: 
5 Fig. 1 is an illustration of a prior art SIP architecture; 

Fig. 2 is an illustrative embodiment of the SIP architecture modified to 
accomplish communication with a home Networked Appliance system according to the 
present invention; 

Fig. 3 shows a functional network architecture showing UAS devices which 
lo;^ cannot directly communicate with each other; and 

Fig. 4 is an illustration of a SIP Networked Appliance system in which 
authentication, authorization, address mapping and protocol translation have been outsourced 
^1^ to a SIP Proxy server, according to a further aspect of the invention. 

Q 

1 DESCRIPTION OF ILLUSTRATIVE EXEMPLARY EMBODIMENTS 

H; According to the present invention SIP is to be used as the basic architecture 

M; to implement remote appliance control. However, before it can be used for this purpose, 
certain changes must be made. In particular, in SIP, the names that are found in the "To:" 
and "From:" fields are encoded as Universal Resource Locators (URL). Current 

2 0 implementations support SIP and PHONE URLs. However, a new type of URL must be 

defined for Networked Appliance systems without changing the nature of the protocol. This 
new URL type allows for "user friendly" discovery of the appliance address. An example, 
using the service URL syntax defined in RFC2609; but, without the location information 
(which has already been determined via the SIP routing) and without the "sip:" prefix would 
25 be: 

d=lamp,r=bedroom 
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By base64 encoding this URL (and potentially encrypting it to avoid revealing information 
about the types of devices contained in the domain) it is possible to structure this URL as part 
of a SIP URL; 

sip:a458fauzu3k3z@stan. home.net 
5 Thus, the existing structure of <entity>@<location> is maintained even when extended to 
accommodate appliances. 

SIP was initially created with call set-up in mind. It is designed for 
establishing a relationship, or session, between two endpoints such that ongoing bearer paths 
can be established between them. This structure could be generalized for 'short-lived' 

IQO. connections if the connection establishment phase of SEP were removed and the SIP payload 

'H 

^-j generalized. The difference between the current way in which SIP is used and the 

modifications according to the invention is analogous in many ways to the difference 
'¥i between TCP and UDP or other Session/Datagram protocols. 

Q A new method is being defined as part of the initiative to use SIP for Instant 

157=1 Messaging. This method, called DO meets the requirements for Networked Appliance 
]2. systems and can carry payloads other than Session Description Protocol (SDP), which is the 
typical MIME payload for the SIP INVITE messages. Unlike standard SIP bodies or 
payloads that carry communications information, the DO type contains control and query 
conrmiands specific for directing and receiving status information from Networked 
20 Appliances. Any MIME type could be used as the payload of a SIP command and new 
MIME types could easily be defined for commands or queries (Action Languages) for a 
particular class of Networked Appliances. An example of this new MIME type is the Device 
Messaging Protocol (DMP). DMP is an XML-based specification similar to Universal Plug 
'n Play's Device Control Protocol. See, UPnP Device Control Protocol, www.upnp.org. 
25 Thus, a DO message would carry the command that is appropriate for the target appliance, 
such as "Turn The Light On," or a query, such as "What is the temperature." The command 
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would trigger a single response, indicative of its result, which would be carried by the 
standard SIP response mechanisms. 

In addition, when a device registers with a Proxy (via the REGISTER 
message) a description of that device must be conveyed. This is achieved with a Device 
5 Description Protocol (DDP) to carry this information. Like the DMP, it is XML-based. 

The request URI of the DO type request is a normal SIP URL identifying the 
party to whom the message is directed. There is no need to established a session or 
connection ahead of time, as may be the case with conventional SIP. The sender places the 
URL for the desired recipient in the mandatory "To" field. The "From" field identifies the 
log originator of the message. The message must also contain a Call-ID. In SIP, the Call-ID is 

H 

used to associated a group of requests with the same session. 
,y Each message contains a Cseq, which is a sequence number plus the name of 

g the method of the request. The Cseq uniquely identifies each message in the session, and 
increases for each subsequent message. Each DO type also carries a "Via header." Via 
headers contain a trace of the BP addresses or FQDNs of the system that the request traversed. 
' As a request travels from proxy to proxy toward the recipient, each adds its address, 
l^p "pushing" them into a header, much like the operation of a stack. The stack of addresses is 
reflected in the response, and each proxy "pops" the top address off, and uses that to 
determine where to send the response. Clients using the DO extension must insert a 
2 0 "Contact" header into the request (Contact is used for routing of requests in the reverse 
direction, from the target of the original message to the initiator of the original message). 
The message also contains a body. The body contains the message to be rendered by the 
recipient. SIP uses the standard MIME headers (Content-Type, Content-Length, and 
Content-Encoding) to identify the content. The request may be sent using UDP or TCP or 
2 5 SCTP transport. Reliability is guaranteed over UDP and congestion control is provided 
through a simple retransmission. 
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The SIP DO type has the following format and nine parts: 
DO sip: user2@domain.com SIP/2.0 

(1) Via:[SIP/2.0/UPD userlpc.domainxom], 

(2) From:[sip:userl@domain.com], 

(3) To:[sip: user2@domain.com], 

(4) Contact: [sip: userl@userlpc.domain.com], 

(5) Call-ID:[asd88asd77a@ 1.2.3.4], 

(6) Cseq:[l MESSAGE] 

(7) Content-Type: [text/plain], 

(8) Content-Length: [18], and 

(9) Body [e.g., "Watson, come here."]. 

The portions in square brackets indicate examples of content. 

This structure establishes synchronous communication with Networked 
Appliances. However, it is also necessary to establish asynchronous communications. For 
example, in order to be notified when an alarm goes off in your home, a certain temperature 
is reached, or when someone rings your doorbell, the system must be capable of 
asynchronous communication. 

The SIP Instant Messaging system defines two new primitives, SUBSCRIBE 
and NOTIFY that can be used to achieve asynchronous communications. When these two 
methods are used in conjunction with the proposed addressing scheme and the Device 
Messaging Protocol MIME type, then event notification from and between Networked 
Appliances is enabled. 

Further details of the modification of SIP to handle Networked Appliances is 
set forth in the above-identified co-pending application which is incorporated herein by 
reference. 



APP 1300 



• 



Fig. 1 shows a typical prior art SIP architecture. In this arrangement, a client, 
e.g., an Internet phone user, employs a SIP User Agent application operating as a client, i.e., 
SIP UAC 100, to initiate a SEP communication with one or more User Agent Servers (UAS) 
which may be associated with an intended recipient of an Internet phone call. This system 
5 supports three different types of architectures which permit remote communication with 
networked devices. The actual implementations may use any combination of the three 
architectures. 

In the first arrangement, the client application UAC 100 is able to directly 
connect to and interact with one of several UAS devices 1 10, 1 12, 1 14, 1 16 and 118. In this 

O 

IGQ: case the client establishes contact directly with the UAS 1 10 at the recipient via path 130. 
^4 The second architecture has the client application interact with a SIP proxy 104 in the 
iH Internet in order to communicate with networked devices, e.g., Internet phones. In the 
il second architecture, another SIP proxy 104 passes communications from UAC 100 to one of 
13 the various SIP UAS devices, e.g. UAS 110, via path 132. 
lO With the third arrangement, the conventional SIP message or request is first 

routed from UAC 100 to the Internet SIP Proxy server 104, which processes it and sends it to 
the SIP Proxy server 108. This Proxy 108 then sends the request to one of the several UASs 
1 10, 1 12, 1 14, 116, 118 associated with it. Each of the UASs may be at separate locations, 
e.g., at the homes of individuals selected to receive the messages, and are embedded in or 
2 0 attached to devices, such as a telephone instrument. Assuming the request is for the home 
associated with SIP UAS 116, the message is delivered to it and the device attached to it. 
Based on the message, UAS 116 operates the device according to the message. As shown by 
arrows or paths 134, 136, 138, 140, each of the UAS devices can communicate directly with 
each other. 

2 5 Before the UAS 1 16 processes the message and sends the instruction to the 

device, it must determine that the message was intended for it, and it was sent by an 
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authorized individual. Thus, UAS 1 16, and all of the other UASs, must check the destination 
address of the messages, and make sure that the messages are authorized and are in a format 
it can interpret. Further, the UAS must be able to translate the message into a format that the 
attached device can understand and respond to. 



SUBSCRIBE and NOTIFY methods, the various SIP architectures can be used to 
communicate with Networked Appliances. The architecture of such a system is shown in 
Fig. 2. It allows a client application to interact with Networked Appliances in the home 
domain 200. The wide area network 300, e.g. the Internet, is used to carry messages from a 

Q 

IQQ client application at SIP UAC 100 to an external proxy 108 (e.g., in the Networked Appliance 
==1 Service Provider's network). This proxy is in communications with a number of residential 
3 gateways (RGW) in the form of a Home Firewall/Network Address Translator (NAT). Each 
3 containing a proxy server 116, which may be a UAS or lead to other UAS devices. Once 
J™: authenticated, these messages are allowed through the firewall. Inside the home domain 200, 
isl messages are transported over the Home LAN 201 to the appropriate Networked Appliance. 
The devices may either be "IP capable", i.e., they can process the incoming SIP messages 
themselves, such as device 202, or Non-IP-capable appliances, such as appliance 206. Non- 
IP-capable appliances require an appliance controller 204 to translate the SIP control requests 
to the specific protocol of the appliance. 
20 All communications between the Proxy server and the Home Firewall/NAT 

are assumed to be secure. In the case shown in Fig. 2 the Proxy server is physically located 
in the home domain's gateway device 1 16. This Proxy server can provide a number of 
functions including: 



5 



If the SIP protocol is extended as suggested above to include DO, 



Authentication and authorization of each message/request. 



25 



Address mapping/resolution for Networked Appliances within the home 



domain. 
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• Security for the Home Firewall/NAT (RGW) for communications to the 
outside world. 

• Networked Appliance mobility and tracking service. 

• Message protocol mapping for client applications. By taking this approach, a 
variety of client applications can be supported for remote controlling 
Networked Appliances. 

• A charging point for services. 

When the proxy is in the gateway device, it requires a lot of functionality, 
which may place onerous requirements on the gateway device in terms of performance, 
memory, etc. Since gateway devices may not have the resources required to support the 
proxy functionality previously described, much of the functionality could be moved to the 
service provider proxy. If a secure connection (e.g., IPsec tunnel) existed between the 
external proxy 108 and the gateway proxy 116*, the gateway proxy would only be required to 
forward the SIP messages to the appropriate UA. The split of functionality in the gateway 
proxy does not have to be an "all or nothing" decision, but could be split equally (or 
unequally) between the two proxies. The advantages of this approach are: 

• Administration of the SIP Proxy is performed centrally, avoiding a distributed 
systems issue. 

• If the local link to the home were to fail, functionality would still be available 
through the Service Provider Proxy 108 from the wide area 300, e.g. so the 
system could re-direct messages to another home, for example. 

• Configuration of the RGW is kept to a minimum, although it may still be 
necessary to perform some limited configuration such as the creation of an 
IPsec tunnel. 

• The costs of making the Service Provider fault tolerant can be amortized 
across multiple homes. 



-14- 



APP 1300 



In the arrangement of Fig. 2 the SIP UAS (as shown in Fig. 1) is considered to 
be the residential gateway (RGW). However, in an alternative embodiment, the internet 
capable appHance 202 and the apphance controller 204 may be considered SIP UAS devices, 
with the RGW as their proxy server. However, in the arrangement the UAS device would not 
5 need address mapping capability, unless for example the controller 204 controlled more than 
one appliance. 

The SIP architecture, even as modified as suggested in the above-identified 
co-pending application, has some shortcomings when applied to Networked Appliances. In 
particular, the current SIP architecture has the SIP UAS perform the functions of 

Q 

IQO authentication and authorization, address checking and mapping, and protocol translation, if 

"-=1 

==4 necessary. The problem with this is that agents are deployed in small, embedded devices 
=0 with limited resources for processing and memory storage. In addition, since the agents are 

distributed, the management and administration of these functions is difficult and has to be 

repeated in each agent. 

ife l As shown in Fig. 2, a Networked Appliances system is implemented in which 

a client, i.e., a homeowner, remotely controls appliances in his home by transmitting control 
signals to the home over the Internet using a Session Initiation Protocol (SIP) architecture. 
All control communications from outside the home domain 100 to any appliance within that 
domain must pass through the service provider proxy 108. However, the appliances in the 

2 0 form of UAS devices in the home domain as shown in Fig. 1 and Fig. 2 can communicate 
with each other over the Home LAN 201. However, the system according to the present 
invention differs from the prior art SIP system shown in Figs. 1 and 2 in that the 
communications paths between UAS 110-118 (i.e., paths 134-140) have been eliminated. 
Thus, all UAS communications between UAS devices within the home domain 100 must go 

2 5 through home Proxy server 116' as shown in Fig. 3. All communications with these UAS 

devices from outside the home domain must be through the service proxy 108. In addition, in 
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Fig. 3 the authentication and authorization functions have been moved from the UASs to 
Proxy server 1 16' or the service provider proxy server 108. This requires the access control 
information for each UAS to be located in the SIP Proxy server 1 16' or 108. 

Fig. 3 is a functional representation of the SIP Architecture for supporting 
5 Networked Appliances as modified according to the present invention. It is based on the 
Messaging via Proxy architecture. In Fig. 3 a request for operation of a Networked 
Appliance or the status thereof, begins in an originating client application at SIP UAC 100 
(originating application). SIP UAC 100 is used by the originating application to generate and 
send appliance messages (DO) to the SIP Proxy 108 hosted by either the service provider or 
los the home RGW. The SIP proxy 108 in the service provider domain resolves the address of 
-4 the appliance to be communicated with (including the appropriate Home domain RGW) by 
M means of a lookup in a location database 146. The SIP Proxy forwards appliance messages 

from the Client SIP UA 100 to the SIP Proxy 1 16' in the Home Domain RGW or, via a secure 
connection, directly to the SIP UAS in the target device. 
15 J The location database 146 contains location information for all registered 

H appliances within the home domains. This database is populated with information gathered 
^"^^ by the service provider SIP Proxy 108 during a registration procedure. In particular, 

REGISTER messages are sent to Proxy 108 to register the location of the client and each 
appliance. In the case of appliances, the registration may merely be that the appliance is in 
2 0 home domain 200. Further, even this may not be registered, only the IP address of home 

domain 200. In this case the user is expected to know which appliances are available in his 
home domain. A message addressed to a specific appliance in that domain will be routed to 
the appliance by address mapping in the proxy. In the prior art, this was done in Proxy 116'. 
However, according to the present invention, it is accomplished in Proxy 108. While not 
25 shown. Proxy 108 is connected to a plurality of UAS devices 1 16' which control various 
home domains 200. 
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The SIP Proxy 1 16' (which is operating as a UAS) in the home domain 
residential gateway provides the gateway between Appliances in the home domain and 
entities in the wide area. Other RGW functions, such as Firewall and NAT, may be co- 
located with the RGW SIP Proxy 116'. A SIP appliance or appliance controller terminates 
SEP appliance messages from the originating application SIP UAC 100. However, the 
addressing information for these devices is mapped in the Proxy 108. In the case of non-IP 
appliance 108, the messaging information from the SEP message passes through device 116' 
to the line leading to controller 204 and is passed to the Interworking Unit 208. The 
Interworking Unit 206 will translate the appliance message into a form useable by the 
appliance and convert status information from the appliance into a form usable by the 
network. However, the translation of the appliance message in the language of the appliance 
can also be achieved in Proxy 108. Thus, the Interworking Unit 208 may be eliminated 
according to the invention, except perhaps for providing status information from the 
appliance. 

The IP-capable appliance 202 also terminates SIP appliance control messages 
from the originating application SIP UAC 100, and retrieves the appliance control status 
information for the appliance application, acting on it directly without any requirement for an 
intervening Interworking Unit 206 or an appliance controller 204 which may be needed for 
the non-IP appliance. 

Fig. 4 is a functional representation of the out-sourcing of the authentication, 
authorization, translation and address mapping functions from the UAS devices to the Service 
Provider Proxy 108. In particular, when a message is sent to a particular UAS 310, the Proxy 
320 makes sure it is from an authentic source, e.g., the home owner. This can be by means of 
a password, which instead of being stored in the UAS, is stored in the Proxy and is checked 
by it. Even if the source is authentic, the requested action may not be one authorized to that 
individual. For example, a parent may be authorized to control any function, but may set up 
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the system so that a child may only be authorized to turn on the lights, but not to adjust to 
heat. Thus, the Proxy checks the message from the authorized individual to see if that 
individual has the authority to control the device in question. The computation power needed 
to perform this function has now been moved to the Proxy 320 from the UAS 310. As a 
5 result, the UASs may be made smaller, consume less power, need less memory and less 

computing power. As a result, a proliferation of UASs does not unduly burden the system, 
since these functions for the UASs can be performed efficiently in the Proxy. 

If the Proxy determines that the authentication and authorization are correct, 
the control message is then sent on to the UAS 310. The message is then delivered by UAS 
iQjS 310 to appliance controller 330, which can then perform the requested operation, i.e., turn on 
Q the lamp 340. 

'2 Further, as also shown in Fig. 4, in addition to the authentication and 

%t authorization functions, the address mapping and protocol translation functions are also 
L. relocated from the UAS 310 to the Proxy server 320. For a SIP Proxy to perform this address 
1^"] mapping and protocol translation it will require: (1) an address mapping table — which can 
'i- be populated for each device using SIP REGISTER messages and (2) translation "rules" for 
Hf each type of device protocol — which needs to be "provisioned" ahead of time. In particular, 
when a device issues a REGISTER message to the SIP Proxy it will have to include (in the 
payload of the message using the Device Description Protocol MIME type): (1) a description 
2 0 of the type of device protocol it uses and (2) the physical device address. 

The external address for the message, e.g., "lightl@UAS.home.net" is 
translated into the in home LAN address A2 by the Proxy 320, so the UAS 310 does not need 
to do it. Further, the command "Turn On" is translated into the X.IO code BON which the 
appliance controller 330 understands and can respond to. 
25 With this arrangement, instead of having to perform address translation and 

protocol mapping, the UAS 310 only has to extract (i.e. parse) the address and protocol 
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message from the message sent to the UAS from the SIP Proxy. Parsing is a much more 
lightweight operation than address mapping and protocol translation. 

In previous solutions, all of the functionality had to be placed in the endpoint 
device. This means that every endpoint had to have sufficient processing capability to be 
able to perform all processing necessary, even though the utilization may be very low. The 
present invention allows statistical multiplexing of resources across a large number of 
endpoints, thus resulting in an overall cost saving. Further, there are also market possibilities 
which become available with this technique. Increased reliance on certain network 
infrastructure means that a user (customer, homeowner, etc.) is more likely to be locked in to 
this provider. This is preferable from the perspective of the network owner. 

In addition, this arrangement also provides a point in the network where usage 
and charging/billing records can be collected. Based on this approach, it is possible to bill 
flat rate for control of some commodity appliances (e.g., lamps, refrigerators), but charge for 
control of other (premium) devices (e.g., high-end TVs, DVD players). 

The present invention differs from some basic concepts of the prior art SIP 
architecture. The invention involves some configuration of the SIP endpoints so that they 
will always communicate via the service provider proxy, as opposed to conmiunicating 
directly with each other. This change enables the service provider to control access and 
provide value-add services to the home network. 

As illustrated above, the present invention is applicable to Networked 
Appliances. However the out-sourcing of authentication and authorization elements is also 
applicable to SIP for Voice over IP, SIP for Instant Messaging, and SIP for other services. 
Further this functionality may be used for media translation performed by proxies, e.g., text 
messages translated to audio and/or audio messages translated to text. It can also be 
incorporated into Call Agent/Softswitch products (like those sold by Telcordia) that also 
support the SIP protocol. 
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SIP, with the newly proposed DO, SUBSCRIBE, and NOTIFY messages, plus 
the new MIME types, and new mechanism for encoding service information in the "To:" 
field can provide the support necessary for communication with Networked Appliances from 
a wide area network. This enables leveraging the existing SIP infrastructure and capabilities 
(e.g., hop-by-hop routing and security) for a new problem domain — Networked Appliances. 
Further, the out-sourcing of some UAS functions to Proxies allows the system to be more 
cost effective and provides additional marketing opportunities for system owners. 

While the invention has been particularly shown and described with reference 
to a preferred embodiment thereof, it will be understood by those skilled in the art that 
various changes in form and details may be made therein without departing from the spirit 
and scope of the invention. 
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